ipvs: SNAT packet replies only for NATed connections
authorJulian Anastasov <ja@ssi.bg>
Sat, 29 Apr 2017 17:33:09 +0000 (20:33 +0300)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Thu, 27 Jul 2017 22:08:00 +0000 (15:08 -0700)
commit445ea10969aade3f9711b262756099717a5fe6bb
treea9a66e47df4d585545fa3e5ee28334b264c29155
parent33780512d9fe64872b3c46596d2c6d812be98fc9
ipvs: SNAT packet replies only for NATed connections

commit 3c5ab3f395d66a9e4e937fcfdf6ebc63894f028b upstream.

We do not check if packet from real server is for NAT
connection before performing SNAT. This causes problems
for setups that use DR/TUN and allow local clients to
access the real server directly, for example:

- local client in director creates IPVS-DR/TUN connection
CIP->VIP and the request packets are routed to RIP.
Talks are finished but IPVS connection is not expired yet.

- second local client creates non-IPVS connection CIP->RIP
with same reply tuple RIP->CIP and when replies are received
on LOCAL_IN we wrongly assign them for the first client
connection because RIP->CIP matches the reply direction.
As result, IPVS SNATs replies for non-IPVS connections.

The problem is more visible to local UDP clients but in rare
cases it can happen also for TCP or remote clients when the
real server sends the reply traffic via the director.

So, better to be more precise for the reply traffic.
As replies are not expected for DR/TUN connections, better
to not touch them.

Reported-by: Nick Moriarty <nick.moriarty@york.ac.uk>
Tested-by: Nick Moriarty <nick.moriarty@york.ac.uk>
Signed-off-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
net/netfilter/ipvs/ip_vs_core.c